1. Field of the Invention
The current invention relates to peer-to-peer communication between different types of Internet hosts, and, in particular, to peer-to-peer call signaling between different types of Internet hosts.
2. Description of the Related Art
The Internet is a network of networks that provides access to innumerable instances of many types of information. One segment of the Internet is the world-wide web (www or the Web), which is a collection of interlinked hypertext documents and services accessible via uniform resource locator (URL) addresses. The Web operates in a client-server mode, where a client retrieves information from a server. Another model for Internet communication is peer-to-peer (P2P) communication, where two computers communicate as peers with each other. Examples of P2P applications include file-sharing programs and Internet telephony applications such as voice-over-Internet protocol (VoIP) and multimedia conferencing applications.
SIP
In a typical peer-to-peer application, the logical connectivity between the two peers is dynamic in nature, where connections are set up when needed to establish a session and torn down when the session is finished. In the Internet environment, one widely accepted call-signaling protocol for logical connectivity between peer hosts is the Session Initiation Protocol (SIP), described in RFC 3261, titled “SIP: Session Initiation Protocol,” incorporated herein by reference in its entirety (available online at http://www.ietf.org/rfc/rfc3261.txt). SIP provides extensive capabilities as well as flexibility in call signaling.
FIG. 1 shows a sample data flow diagram for a basic call setup between SIP host 101 and SIP host 102. Message flow in FIG. 1 proceeds from top to bottom. Hosts 101 and 102 are each running User Agents (UAs). Host 101 hosts a first user, user1, of company A, identified by SIP universal resource identifier (SIP URI) sip:user1@companyA.com, while host 102 hosts a second user, user2, of company B, identified by SIP URI sip:user2@companyB.com. The “sip:” prefixes are used to identify the URIs as SIP URIs. The “sip:” prefix may be omitted in some circumstances, such as when the context clearly indicates that the URI is a SIP URI.
Host 101's UA initiates a call to host 102 by sending INVITE message 101a to host 102's UA. Host 102 might respond with one or more provisional response messages (also known as “1xx” messages) (not shown), which contain status information and indicate that request processing is in progress. If host 102 accepts the call request, then host 102 transmits OK message 102a (an OK messages is also known as a “200” message). Host 101 then responds with ACK (acknowledgment) message 101b, which completes the call set-up transaction. This establishes application-layer connectivity 101c between host 101 and host 102 allowing transmission of data in accordance with the parameters established between hosts 101 and 102 through the above-described exchange of messages.
The parameters of the application-layer connection are encoded in the previously described SIP messages. The parameters may be encoded in the format specified by the Session Description Protocol (SDP), described in RFC 2327 and incorporated herein by reference in its entirety (available online at http://www.ietf.org/rfc/rfc2327.txt). Examples of encoded parameter information include the IP address and UDP (user datagram protocol) port number to be used by the application traffic, called bearer traffic. SIP messages can also include information in addition to that provided by standard SIP headers and SDP. When host 101 wishes to terminate the call, host 101 transmits BYE message 101d to host 102, which initiates session tear-down. Host 102 then responds with OK message 102b, and the session is terminated.
SIP is a flexible protocol which allows many extensions to accommodate different situations. For example, SIP body messages may be encoded in accordance with the Multipurpose Internet Mail Extension (MIME) standard. SIP message bodies may contain multiple sections, where, using a “handling” parameter, some sections may be defined as required and other sections may be defined as optional. If a SIP proxy receives a SIP message with an optional section that the SIP proxy does not understand, then the SIP proxy ignores that optional section and processes the SIP message as if it did not contain that optional section. However, if a SIP proxy receives a SIP message with a required section that the SIP proxy does not understand, then the SIP proxy should reject the message and respond with a suitable error code.
SIP Proxies
FIG. 2 shows an example of using SIP routing to set up a call in network 200, which comprises hosts 201 and 206. Hosts 201 and 206 (1) are in different locations, (2) are not directly connected, and (3) are separated by various intermediaries. The intermediaries include SIP proxy servers (proxies) 202, 203, 204, and 205. SIP proxies are logical entities whose functions include (1) forwarding SIP messages towards their proper destinations and (2) providing enhanced services to SIP calls when appropriate.
Host 201 hosts a first user whose SIP URI is sip:user1@marketing.location1.companyABC.com and who is in the marketing department at location 1 of ABC company. The first user wants to establish a session with a second user whose SIP URI is sip:user2@sales.location2.companyABC.com, who is in the sales department at location 2, also of ABC company, and who is hosted by host 206. As part of the user login process, the user's host registers with a corresponding home SIP proxy, where the host sends a REGISTER message to the corresponding home SIP proxy, and the home SIP proxy indicates acceptance of the registration by replying with an OK message. Thus, (i) host 201 sends a REGISTER message to SIP proxy 202, whose SIP URI is marketing.location1.companyABC.com, (ii) SIP proxy 202 responds with an OK message to host 201, (iii) host 206 sends a REGISTER message to SIP proxy 205, whose SIP URI is sales.location2.companyABC.com, and (iv) SIP proxy 205 responds with an OK message to host 206. These REGISTER and OK messages are not shown in FIG. 2.
When the first user indicates a desire to call the second user, host 201 generates and sends INVITE message 201a, for the second user, to home SIP proxy 202 via IP network cloud 207. INVITE message 201a indicates that it is from user1@marketing.location1.companyABC.com and intended for, i.e., addressed to, user2@sales.location2.companyABC.com. Based on the addressee, SIP proxy 202 determines that INVITE message 201a is for a recipient at another location, and sends corresponding INVITE message 202a via IP network cloud 208 to affiliated gateway SIP proxy 203, whose SIP URI is gateway.location1.companyABC.com. INVITE message 202a is substantially identical to INVITE message 201a, but is modified to indicate its passage via SIP proxy 202 using the “via” header section that is in INVITE messages for delineating their passage through a network.
Based on the addressee in INVITE message 202a, gateway SIP proxy 203 determines that INVITE message 202a is for a recipient at location 2, and sends corresponding INVITE message 203a via IP network cloud 209 to location 2 gateway SIP proxy 204, whose SIP URI is gateway.location2.companyABC.com. INVITE message 203a is substantially identical to INVITE message 202a, but is modified to indicate passage via SIP proxy 203. Based on the addressee in INVITE message 203a, location 2 gateway SIP proxy 204 determines that INVITE message 203a is for a recipient in the sales department at location 2, and sends corresponding INVITE message 204a via IP network cloud 210 to location 2 sales SIP proxy 205, whose SIP URI is sales.location2.companyABC.com. SIP proxy 205 is the home SIP proxy for the second user at host 206. INVITE message 204a is substantially identical to INVITE message 203a, but is modified to indicate passage via SIP proxy 204.
Based on the addressee in INVITE message 204a, SIP proxy 205 determines that INVITE message 204a is for a user at host 206, and sends corresponding INVITE message 205a via IP network cloud 211 to host 206, where the second user is registered. INVITE message 205a is substantially identical to INVITE message 204a, but is modified to indicate passage via SIP proxy 205. If the second user indicates acceptance of the invitation, then host 206 responds with OK message 206a addressed to the first user. Since INVITE message 205a listed the SIP proxies traversed to arrive at host 206, OK message 206a can specify, in a “via” header section, the reverse route as the path for OK message 206a. 
As OK message 206a traverses the reverse route, traversed SIP proxies are removed from the “via” header section. OK message 206a goes first to SIP proxy 205 via IP network 211, next, it is forwarded as substantially identical OK message 205b to SIP proxy 204 via IP network 210. Then, the OK message is forwarded as substantially identical OK message 204b to SIP proxy 203 via IP network 209, then it is forwarded as substantially identical OK message 203b to SIP proxy 202 via IP network 208. Finally, the OK message is forwarded as substantially identical OK message 202b to host 201, where the first user is registered. Host 201 would then reply with an acknowledgement ACK message (not shown) which would follow the same SIP proxy route as the INVITE message and would complete the call set-up procedure.
It should be noted that IP network clouds 207, 208, 209, 210, and 211 can comprise zero or more network components such as hubs, switches, bridges, and routers. Furthermore, IP network clouds 207, 208, 209, 210, and 211 might share one or more network components among themselves and may all be interconnected. As noted, as SIP messages transit through proxies, each proxy can modify the SIP message. The SIP specification describes the extent of allowable modifications. To support some advanced features, a SIP proxy may modify SIP messages beyond the extent allowed in the specification. One example of such an advanced feature is back-to-back user agent (B2BUA) mode, where the SIP proxy acts as an endpoint of the incoming SIP call from the originator, and generates a new SIP call towards the destination. The SIP proxy then keeps track of both calls and coordinates them.
IPv6
Currently, the commonly used version of the Internet Protocol (IP) is IP version 4 (IPv4). In the early 1990s, the Internet Engineering Task Force (IETF) estimated that the IPv4 address space was nearing exhaustion. Based on this, the IETF initiated work on the next generation of IP to solve this address-shortage problem. The result was IP version 6 (IPv6). IPv6 has a much larger address space than IPv4 because IPv6 uses 128-bit addresses as opposed to IPv4's 32-bit addresses. In addition to the larger address space, IPv6 has other enhanced features, such as a better-structured address space, better multicast support, better mobility support, neighbor discovery, support for authentication and payload encryption, and quality of service (QoS) support. IPv6 may be said to represent a different address family from IPv4.
During the development of IPv6, the IETF chartered a working group (WG) to investigate techniques to prolong the useful life of IPv4. A number of techniques were developed and are being used today, such as Classless Inter-domain Routing (CIDR), Dynamic Host Configuration Protocol (DHCP), Allocation for private address (as described in RFC 1918), Network Address Translation (NAT), and various tunneling technologies such as Multi-Protocol Label Switching (MPLS) and Generic Routing Encapsulation (GRE).
Although these techniques are in wide use today, there is consensus in the industry that IPv4 is near the end of its life cycle and that deployment of IPv6 will become common soon. Several reasons, outlined below, account for this. First, much of the existing IPv4 address space has been assigned to U.S.-based organizations. Meanwhile, other countries will be deploying more IP systems, and countries with large populations would likely install IPv6 systems. Second, while, in the early 1990s, IP hosts mostly comprised PCs and servers, today, many other devices, such as cell phones, automobiles, TV set-top boxes, and domestic appliances, are using IP for communication. This requires many more IP addresses. Third, the various IPv4 address-preservation techniques have shortcomings. For example, using NAT with many applications requires the use of an application-specific application layer gateway (ALG) in order to appropriately perform port address translations. The use of ALGs in NAT increases complexity and cost and degrades performance. Other techniques have similar limitations. Therefore, many organizations, service providers, and enterprises are investigating methods and systems for transitioning from IPv4 to IPv6.
IPv4 to IPv6 Transition
A sizeable network cannot transition from IPv4 to IPv6 in an instant. The transition process is likely to take months or even years as IPv4 systems are replaced with IPv6 systems. Therefore, the two versions will coexist for some time in a network. The IETF has developed a number of techniques to enable interoperability between IPv4 and IPv6 hosts to ease the transition. Each technique addresses a specific interoperability configuration. Examples of these techniques include 6over4 (described in RFC 3056), Intra-Site Automatic Tunnel Addressing Protocol (ISATAP; described in RFC 4214), Teredo (described in RFC 4380), and Dual Stack Transition Mechanism (DSTM). A network may use any number of these techniques during a transition from IPv4 to IPv6.
DSTM
DSTM (dual stack transition mechanism) is a protocol interworking mechanism and is described in (1) the IETF draft titled “Dual Stack IPv6 Dominant Transition Mechanism (DSTM),” by Jim Bound et al., October 2005, (available online at http://www.ipv6.rennes.enst-bretagne.fr/dstm/doc/draft-bound-dstm-exp-04.txt) and (2) the 2004 IEEE International Conference on Communications article titled “An IPv4-to-IPv6 dual stack transition mechanism supporting transparent connections between IPv6 hosts and IPv4 hosts in integrated IPv6/IPv4 network,” by Eun-Young Park et al., June 2004 (available online from ieeexplore.ieee.org), both incorporated herein by reference in their entireties.
FIG. 3 shows sample hybrid network 300, which comprises IPv6 network 305 and IPv4 network 306. Network 300 uses DSTM to allow communication between DSTM-enabled host (or end-point) 301 and IPv4 host (or end-point) 302. DSTM host 301, which is capable of handling both IPv4 and IPv6 communication, is connected to IPv6 network 305 and has IPv6 address A. IPv4 host 302, which is capable of handling IPv4—but not IPv6—communication, is connected to IPv4 network 306 and has IPv4 address B. Network 300 further comprises (i) tunnel end-point (TEP) 303, which has IPv6 address C and connects IPv6 network 305 and IPv4 network 306, and (ii) DSTM address server 304, which is connected to IPv6 network 305.
DSTM host 301 can have a permanent IPv4 assigned to it in addition to IPv6 address A, but since that may be an inefficient use of the limited address space available with IPv4, DSTM host 301 instead uses a temporary IPv4 address obtained from DSTM address server 304 when necessary. If DSTM host 301 determines that it needs to send data packet payload 301b(ii) to IPv4 host 302, then DSTM host 301 sends IPv4 address request 301a to DSTM address server 304. DSTM address server 304 responds with IPv4 address assignment 304a which includes temporary IPv4 address D as well as IPv6 address C for corresponding TEP 303. Alternatively, DSTM host 301 may already possess address C for TEP module 303 prior to the receipt of address assignment 304a, which, therefore, need not include address C.
DSTM host 301 encapsulates payload 301b(ii) with IPv4 header 301b(iii) having source address D and destination address B. Payload 301b(ii) is further encapsulated with IPv6 header 301b(iv) having source address A and destination address C. Packet 301b(i), comprising payload 301b(ii) and headers 301b(iii) and 301b(iv), is then sent to TEP 303 as message 301b via IPv6 network 305. This essentially sets up an IPv4-over-IPv6 tunnel between DSTM host 301 and TEP 303. TEP 303 processes message 301b and, as a result, (1) updates its forwarding table to bind temporary IPv4 address D with IPv6 address A using automatic tunnel binding, (2) removes IPv6 packet header 301b(iv) from packet 301b(i) and (3) forwards corresponding packet 303a(i) to IPv4 host 302 as message 303a via IPv4 network 306. Packet 303a(i) comprises (1) payload 303a(ii), which is substantially identical to payload 301b(ii), and (2) IPv4 header 303a(iii), which is substantially identical to IPv4 header 301b(iii). Additional packets from DSTM host 301 to IPv4 host 302 will follow the same path and procedure.
Packets from IPv4 host 302 back to DSTM host 301 also go through TEP 303 and are processed in a mirrored way (not shown). A payload packet from IPv4 host 302 to DSTM host 301 is encapsulated with an IPv4 header having source address B and destination address D and is delivered to TEP 303 via IPv4 network 306. TEP 303 adds an IPv6 header having source address C and destination address A and delivers the packet to DSTM host 301 via IPv6 network 305. DSTM host 301 then extracts the payload from the received packet. If there is a prolonged period of inactivity between DSTM host 301 and IPv4 hosts connected to IPv4 network 306, such as IPv4 host 302, then TEP 303 purges the address binding of IPv6 address A and temporary IPv4 address D. An alternative to using automatic tunnel binding and tear-down at TEP 303 is having DSTM host 301 use a tunneling signaling protocol to explicitly establish and tear down an IPv4-over-IPv6 tunnel to TEP 303.
DSTM is still an IETF draft, has not yet reached RFC status, and is still subject to changes. DHCP is suggested as the protocol for address request and assignment messages. DSTM has several limitations, outlined below, some of which are particularly relevant for applications that use higher-layer call-signaling protocols such as SIP. The DSTM draft does not provide a mechanism for IPv4 host 302 to initiate communication with DSTM host 301. The steps of obtaining an IPv4 address and setting up the IPv4-over-IPv6 tunnel to TEP 303 adds significant call set-up delay, which may be unacceptable for some critical communication applications. Some applications require the use of a tunneling signaling protocol, rather than automatic tunnel binding, and use of the former adds delay.
Connection Initiation by IPv4 Host
Although, as noted above, the DSTM draft does not specify a procedure to allow an IPv4 host to initiate a connection with an DSTM host, some proposals have been made to address this situation. One proposal is illustrated in FIG. 4.
FIG. 4 shows sample hybrid network 400, comprising DSTM host 401, IPv4 host 402, TEP 403, DSTM address server 404, IPv6 network 405, and IPv4 network 406. These elements of FIG. 4 are similar to corresponding elements of FIG. 3 and are similarly numbered, but with a different prefix. FIG. 4 shows various messages that are also sequentially labeled as steps. DSTM host 401 hosts a first user whose URI is sip:user1@marketing.location1.companyABC.com. Network 400 further comprises IPv4 domain name server (DNS) 407, DNS application-layer gateway (ALG) 408, and IPv6 DNS 409.
If IPv4 host 402 wants to send a data packet to the first user, then IPv4 host 402 first sends DNS query 402a (step 1) to IPv4 DNS 407 in order to get an IPv4 address for sip:user1@marketing.location1.companyABC.com. IPv4 DNS 407 does not find sip:user1@marketing.location1.companyABC.com in its database since that URI is associated with an IPv6 address, and so IPv4 DNS 407 forwards the DNS query as query 407a (step 2) to DNS ALG 408. DNS ALG 408, which is IPv6-capable and aware that query 407a came from an IPv4 DNS, sends corresponding DNS query 408a (step 3) to IPv6 DNS 409 requesting either an IPv4 or IPv6 address for the first user's URI. IPv6 DNS 409 gets the first user's IPv6 address and sends it in message 409a (step 4) to DNS ALG 408.
DNS ALG 408 determines that DSTM service is needed because query 407a was for an IPv4 address but response 409a contained an IPv6 address. DNS ALG 408 sends address request 408b (step 5) to DSTM address server 404 on behalf of the first user. DSTM server 404 then allocates one of the IPv4 addresses in its address pool to the first user and sends to DSTM host 401 address allocation message 404b (step 6), which contains the IPv4 address allocated and the IPv6 address of corresponding TEP 403. DSTM host 401 responds with acknowledgement 401c (step 7) to DSTM address server 404. DSTM address server 404 registers the allocated IPv4 address at IPv6 DNS 409 on behalf of the first user with registration message 404c (step 8).
DSTM address server 404 informs DNS ALG 408 of the allocated IPv4 address assigned to the first user with message 404d (step 9). DNS ALG 408 then responds to query 407a with message 408c (step 10), providing the allocated IPv4 address to IPv4 DNS 407, which in turn forwards corresponding message 407b (step 11) to IPv4 host 402. DSTM address server 404 instructs TEP 403 to bind the IPv6 address of the first user and the allocated IPv4 address of the first user using instruction message 404e (step 12). TEP 403 then responds to instruction message 404e with acknowledgment message 403b (step 13). IPv4 host 402 can then communicate with DSTM host 401 via TEP 403 in a manner similar to that described for hybrid network 300 of FIG. 3.
This procedure to allow IPv4 host 402 to initiate communication requires many steps and transactions which cause significant delay in the initial start up. In addition to this performance issue, the procedure has practical limitations. For example, when IPv4 DNS server 407 fails to locate the first user, it is supposed to immediately forward query 407a to DNS ALG 408. In practice, IPv4 DNS 407 comprises a hierarchy of servers. The servers in the hierarchy will try to exhaustively search for the first user's URI in the IPv4 space before forwarding the request to DNS ALG 408, which increases delay. Also, in practice, DNS ALG 408 will be one of several available DNS ALGs. Thus, either complex policy needs to be loaded to IPv4 DNS 407 so that appropriate DNS ALG 408 can be identified or exhaustive searching of the several available DNS ALGs may be required, increasing delay. Furthermore, the general need to locate appropriate servers and communicate among them increases delay.
The current DSTM mechanism of FIG. 3 is, therefore, essentially only suitable for applications that are based on the client-server model (e.g., web browsing) where some initial delay is acceptable. Furthermore, the current DSTM mechanism does not provide support for call setup invitation from an IPv4 host to a DSTM host, and the above-described proposal of FIG. 4 for such invitation is cumbersome. Additionally, neither the current DSTM mechanism nor the above-described proposal support host mobility.